This invention relates to network servers and to methods of logging client information requests in conjunction with such network servers.
Computers are increasingly becoming interconnected at higher and higher levels through networking technologies. The public Internet is currently the most visible manifestation of this trend. Smaller scale networks, however, are also becoming more widespread.
Such networks allow application programs to be structured using client/server architectures. A server or server process is a provider of services. A client or client process is a consumer of services. A server can service many clients at the same time and regulate their access to shared resources. In most cases, interaction between clients and servers is initiated by clients-servers wait is passively for client requests, and provide data, information, or services in response to such requests.
Servers are available to provide a variety of services. There are file servers, database servers, transaction servers, groupware or mail servers, object servers, Internet World Wide Web (WWW or Web) servers, and many other types of servers.
Many servers record a log of client requests and of the way in which the client requests were handled. Log data is typically recorded in one or more files. This is useful for a variety of purposes. One use for a log file is to troubleshoot client/server operation. Log files can be used for capacity planning, for accounting, and for security purposes. Log files are also frequently used to compile statistical data regarding server usage. This is becoming increasingly important for Internet servers, where advertising revenue depends on the number and nature of client requests for specific content.
Log files are typically formatted in accordance with established standards. For example, there is a log file standard known as the NSCA (National Center for Supercomputer Applications) log format.
When designing a server application, it is necessary to decide upon a log file format. It is also necessary to decide which types of client requests will be logged, which data will be logged from such client requests, and where log files will be created. Generally, there is a tradeoff between efficiency and the amount of data that will be logged; increasing the amount of logged data requires more storage space and generally degrades performance of a server application.
It is difficult to predict the needs of server users. Some might require a high degree of data logging, while others need very little logging. In addition, it has been found that different users prefer their logged data in different formats. One way to address these problems would be to modify the server program for each end user of a server application. This would be impractical, however, for programs that are widely distributed. Another solution would be to log every conceivable item of information. However, this would create huge log files, containing items that would rarely be used. A further alternative would be to provide user-selectable options regarding logging criteria. The problem with this scheme is that it is very difficult to provide enough flexibility to meet the needs of every user.
The inventors have developed a server architecture that allows each end user to log client requests in a different way. In accordance with this architecture, a server program makes calls to one or more logging modules in response to potentially loggable events. The calls are made through a predefined interface, and potential log data is passed to the logging modules.
An end user of the server program can select from a plurality of logging modules that are distributed with the server program, or can create custom logging modules. Each logging module, in response to receiving the potential log data, makes its own decision regarding (a) whether to make a log entry, (b) which data should be included in the log entry, (c) the format that is used for recording the log data; and (d) where to record log entries. In this way, end users are not constrained to any given logging format or set of logging criteria. One end user might use a logging module that records data in conventional NSCA format, while another might create a custom logging module that records data in a customized spreadsheet format.
FIG. 1 illustrates a networked client/server system in accordance with the invention.
FIG. 2 is a block diagram showing pertinent components of a server computer in accordance with the invention.
FIGS. 3 and 4 are flow charts illustrating preferred methodological steps in accordance with the invention.